Grupo 7

En este documento vamos a encontrar el feedback recibido por el grupo 7

---

Semana 1

Feedback General

• Necesitamos tener una BBDD de conocimiento común con el grupo de tarde y otra BBDD de conocimiento privada para nuestro grupo.
• El objetivo ideal con las ONG es conseguir que usen la aplicación realizada para varios años y no sienten que pierden el tiempo.
• Replantearse los puntos a cubrir en el proyecto en caso de los proyectos de ONG. Puede que no todo tenga sentido.
• Tener el commit agreement para la semana siguiente firmado por todos los integrantes del grupo.

Presentación

• La presentación en ingles esta bien hecha
• Bien por guardar los enlaces de IAs.
• No abusar del texto, apoyarse en elementos gráficos como diagramas o gráficas.
• Nos quedamos un poco cortos terminando mas de un minuto antes (En la evaluacion no se puede terminar mas de 1min antes o 1 seg. desp).
• No abusar de las imágenes en la presentación, específicamente la diapositiva del DAFO era demasiada imagen.
• No utilizar imágenes de la asignatura, y que sean imágenes con buena resolución.
• Buscar mencionar y mostrar sólo lo valioso (Mensaje de fuerza, idea clara y desarrollar esa idea).
• Tener cuidado con la velocidad de la speech.
• Pensar bien la estructura y secuenciacion de diapositivas, de forma que todo lo que se explique vaya quedando claro y que los puntos no parezcan desconectados. Ha de dar una sensación de cohesión.

Objetivos

• El objetivo ideal en las ONG es conseguir que lo que hacemos lo usen para varios años, que les guste y no sientan que pierden el tiempo.
• En algunos grupos no quedan claro los objetivos que tratan de perseguirse.

Organización

• Es posible que los roles establecidos así como la estructura de equipos cambie a lo largo del progreso. Tratar de crear una estructura y un plan que sea flexible.
• Considerar no solo roles, si no reparto de responsabilidades, que es más importante que los roles como tal.

Matchmaking

• En el caso de los proyectos ONG, este apartado no tiene tanto sentido.

Competidores

• En el caso de las ONG, dar más atención a herramientas open source ya existentes más que a competidores comerciales y que se pueda usar como base del proyecto.
• En la misma linea, realizar un análisis de las herramientas y soluciones usadas actualmente por las ONG (probablemente Excel en la mayoria de los casos).
• Plantear hacer el un desarrollo hibrido adaptado a algo ya existente (CMS, ej: Wordpress, Django CMS).
• Importante cubrir los competidores tras haber hablado de los caso de uso core y el MVP para que quede mas claro en que sentido compiten con nosotros.

Casos de uso core

• Intentar buscar añadir mas valor a las funcionalidades dadas por las ONG.
• Hay que dar mas peso al las funcionalidades core de la aplicación así como el MVP en las siguientes presentaciones.

Costes

• Hacer un análisis más exhaustivo del TCO, teniendo en cuenta el Coste de Inicio, el de desarrollo y el de mantenimiento. Especialmente util para los proyectos ONG, y tratar de que este último sea lo más asumible posible para las ONG.
• Informar a la ONG sobre el coste de mantener la aplicación activa.

Herramientas

• Dar informes sobre las estadísticas del uso de las aplicaciones usadas, Clockify, GitHub, etc. Y hacer una breve interpretación de las mismas (comparar con semanas anteriores si se tienen datos) para saber si se estan usando y en que medida.
• Plantear la posibilidad de usar herramientas más orientadas al mundo profesional como Slack.

Semana 2

Aspectos importantes para la presentación

• Información precisa y profesional (Evitar expresiones como: "más o menos")
• No quedarse con el micro en la mano para dejarlas libres y: poder señalar o indicar cosas en la presentación
• Ensayar y probar presentación en el aula con antelación. Tener planes por si algo no funciona.
• Los profesores no tienen acceso a la base de conocimientos común. POR AHORA
• Trabajar la entonación.
• Cuestionar todas las direcciones y recomendaciones. Ser capaces de decir "esto no tiene sentido" o proponer mejoras a los profesores.
• Tener cuidado con el texto (Tamaño, cantidad y contraste). Los profesores han de ser capaces de leerlo.
• No es negativo usar varias diapositivas en poco tiempo si es coherente y tiene sentido.
• Añadir QR para feedback al final de las presentaciones.
• Presentar como si fuera un publico nuevo. No hacer referencias a cosas de las semanas anteriores.
• Justificar el tomar en cuenta o no el feedback. (Ej: Discord)
• Añadir una F en las transparencias en las que se ha tenido en cuenta el feedback de la semana anterior (Icono de F y un check por ej)
• Hay que asegurarse de no pasarse del tiempo establecido.
• Tratar de mirar a todos por igual, no solo a los profesores.
• Que se vea bien el número de página
• Hacer uso de los consejos y técnicas de las pildoras de presentación
• Hay que ensayar no solo la presentación, sino el contexto. No depender de imagenes online.
• OJO a la respiración, golpes, atencion a los detalles con el micrófono.
• Demasiados dibujitos. Apoyar algunos dibujos que no estén claros con texto breve (1 o 2 palabras).
• Coherencia entre ideas. Tratar de enlazar diapositivas de alguna forma sin cambios bruscos.

Aspectos Importantes para la PPTX de Evaluación

• Atención al soporte visual. Evitar disonancias
• Demo de los mockups al final para no romper el flujo.
• Mencionar el feeback de cosas anteriores (Marcar diapositivas)
• Aprovechar el espacio de pantalla.
• Revisar los puntos de la presentacióon.
• Incluir revision y estado del commitment agreement (Indicador de cumplimiento).
• Versionar commitment agreement con los comprisos de cada semana.
• 16 minutos de presentacion. Importante la sístesis y especial atencion al documento de directrices del entregable.
• Orden aleatorio durante las evaluaciones y timer llevado por los profesores.
• Se pedirá aleatoriamente a alguien para dar feedback.

Apartados de la PPTX

TCO - Costes

• Contemplar costes de las herramientas de desarollo.
• Costes de herramientas como gh que son de pago en el mundo profesional
• Evitar la palabra mantenimiento: Especificar costes de OPERACIÓN y PERSONAL
• Incorporar costes de integración continua.
• Dar el TCO en el contexto del tiempo (meses, años, etc.).
• Incluir número de usuarios para hacer cálculos.
• No referirse al TCP como "Budget".
• Simular que la ONG está pagando.
• Análisis de potenciales clientes. (Interesante para NOSOTROS - Proyectos de ONGs)
• Desglosar costes fijos. Colocar una tabla con epígrafes.
• Distinguir entre el proyecto y resultado del proyecto. Nosotros vamos a dejar disponible un servicio. "Total cost of OWNERSHIP", no solo operación.
• NO HABLAR DE COSTE DIRECTO o INDIRECTO

Riesgos

• Planes de contingencias para todos los riesgos. (Bien definidos)
• Poner en tabla como en las píldoras -> Centrarse en los mas importantes -> Como los vamos a afrontar (Planes B).
• Métricas para identificar que un riesgo se está produciendo

Business Statement

• Ser formal, que no parezca que estas improvisando. Dar sensación de seguridad aunque no tengas ni idea.
• Disonancia con los elementos visuales.

Core use cases

• Muy poco visual, dificil de seguir. Hacen falta mockups.

SWOT

• Les ha parecido bien el análisis.
• Cambiar iconos a unos más representativos o añadir palabras clave.

Análisis de herramientas

• Mencionar que alternativa se ha elegido finalmente y el porqué (Pros en comparación a las anteriores o motivos por los que las otras se han descartado)

Commitment Agreement

• Documento vivo. Todas las semanas hay que revisarlos, ver si se cumple.
• Historial de versiones.
• Tareas nuevas -> Grado de participación en las tareas.
• Porcentaje de cumplimiento del commitment agreement. Dentro del doc. (Conjunto de docs / carpeta ?).
• Service credits, oportunidad de recuperar puntos o de acumular.

Herramientas y reloj del proyecto

• Dashboard para las estadísticas.
• No sólo añadir el clockify sino también lo mencionado en el commitment agreement del porcentaje de cumplimiento del CA.

Semana 3

• Previo a la presentacion hay que hacer una demo interna y dar feedback
• Rama de presentacion docosaurus para que el resto de la clase de feeback
• No ponerse delante de lo que desea presentar
• Con el grado de compromiso de cada persona contemplar incorporar el concepto de la nota objetivo dentro del commitment agreement. Si alguien tiene como ojbetivo sacar un cinco pelado contemplarlo en el CA.
• Debemos incorporar numero de horas de github actions, con la calculadora de github.
• Añadir la traza del commitment agreement y clausulas y cuantas veces lo ha nviolado.
• Estrategia para gestion de la documentación como codigo. usar alguna metodlogoia para esta tarea
• Los usuarios pilotos tiene que estar totalmente claro: el numero y estado de estos.
• Enseñar la presentación delante de todo el grupo.
• Al final de la presentación realizar una autodefensa de las tareas hechas.
• Probar IA en el enseña para ver si se puede hacer un resumen mayor de la presentación.
• A partir del proximo dia son de 15 minutos. Para ir al grano.
• En el primer sprint ya hay usuarios pilotos, contactar con los usuarios disponibles para comunicarles cuando va a estar disponible el sistema. Cuando se va a desplegar el sistema. Hacer un agenda de usuarios pilotos.
• Habra que hacer un formulario de microsoft para los usuarios pilotos.
• Presentacion siguiente: Hacer presentacion tecnico del desarrollo, una parte inicial tiene que ser un resumen del proyecto/negocio, un 15-20 porciente tienen que ser para las ideas de negocio, killer opeener, elevator spitch, resumen analisis de costes y operación, mejora de equipos en base a roles, resumen estado de commit agreement. El resto tiene que ser el seguimiento de proyecto de desarrollo otro 15-20 para explicar lo que ya esta implementado y enseñarlo sino hay nada mostrar mockups, la parte mas imprtante en torno a 40-50 va a ser la restrispectiva de la semana, de la mitad del sprint, en esta restropectiva tiene que estar la medida del rendimiento del equipo en base a roles.
• Recomendacion una diapositiva para comparar los rendimientos de todo el equipo.
• No solo el estado de los riesgos, sino hablar sobre problemas y soluciones que han salido en el sprint, con mediciones de las soluciones proporcionadas.
• Lecciones aprendidas del trabajo.
• Reloj avance del proyecto cuanto se ha invertido en total. Poner las horas registradas respecto a un total estimado en general (no del proyecto sino del sprint, semana).
• Enlace clockify para acceder al dashboard, una buena forma es hacer una landing page del proyecto.
• Si se cambian las semanas de trabajo en vez de lunes a domingo, de martes a martes, cmabiar las graficas de clockify.
• Si no da tiempo a hacer las tareas, si es necesario cambiar las responsabilidades del sprint1 comunicarlo en la presentación.
• Gestión de usuarios pilotos: Tener muy encuenta el feedback que dan las ONG. Tener toda la información para ellos definida, como accedre a la aplicación, donde esta el formulario... Evaluar que partes del feedback av a ser incorporada y justificar si algo no se mejora.
• Report de uso de inteligencia artificial: Es muy importante.
• Tener medidas de cohesión y acoplamiento, toda medida es revertible. No buscar machar con la medicion del rendimiento.

Semana 4

Feedback a nuestro equipo

• Bluejay configuration
• Poner los criterios de aceptación de los requisitos en el docusaurus y en la descripción de la issue hacer referencia al caso de uso ahí.
• Vídeo de la demo.
• Nombrar cómo se va a planificar en posteriores sprints.
• Cuando queremos que nos den feedback.
• Rendimiento del equipo. Separar el CA del rendimiento del equipo
• Intentar ser convincente con el elevator pitch
• Estrategia de ramificación no hay
• Referenciar en las issues la BGC
• TCO en lugar de seguimiento de costes
• Formulario de iTop (TTR - Tiempo medio de respuesta). Tener en cuenta el tiempo máximo de respuesta.
• TCO - Evolución del TCO (Por ej: 200€/mes cada 1000 usuarios, si se duplica el nº de usuarios, ¿qué pasa con los costes de operación?)
• Nota a la que cada uno aspira (Aunque no lo usemos)
• Versión 3.0 del CA
• Responsable de cada tarea en un doc de responsables
• Meter una recopilación del seguimiento del trabajo de doc y código desde el CA.
• Ver el límite gratuito de actions en un repo público
• HACER LA DOCUMENTACIÓN EN DOCUSAURUS - meter en el docusaurus que se haga una tabla de responsabilidades y una sección de CA. Después pasar el markdown a pdf introduciendo portada, e índice. Mirar el tema del changelog de docusaurus, migrar doc a project. Seguimiento de tareas, etc. https://medium.com/@stheodorejohn/google-docs-integration-in-react-352a15c0b23e Para usar el seguimiento del trabajo desde el docusaurus

Feedback general

• MVP - Qué puede hacer a la ONG que se quede con este sistema y que les haga querer pagar el coste operacional.
• Evolución del coste en función del número de usuarios
• Cálculo de TCO según githubs
• Estimación de horas de workflows
• CA, indicar la gente que no desea sacar buena nota.
• En el CA, anexo de responsables(Enlace a las issues de github) - Evitar 120 docs
• Rendimiento -> Evolución respecto a la semana anterior
• Elevator pitch currado
• Doc de información sobre el dashboard de bluejay
• Doc avanzado del despliegue (React+sprinboot)

Semana que viene

• 15 min de duración
• Asistencia obligatoria
• Hoja de firmas
• Timer controlado por ellos
• Orden aleatorio
• Minitest de las theory pills

Apartados de la PPTX

• Grandes bloques:
  • Introducción del negocio (Resumen del modelo de negocio) 20%
    • Killer opener
    • Elevator pitch
    • Resumen del análisis de competidores
    • Resumen del TCO (Separar CapEX - Horas de desarrollo, infraestructura propia que se va a amortizar en distintos proyectos, personal, licencias de software como producto, amortización de equipos y OpEX desde el punto de vista de Harmony - Coste de proveer el servicio a los clientes, licencias de software como servicio, hosting, cloud, mantenimiento, mejora, customer support, marketing. El coste suele ir al OpEx). Situación actual respecto al esperado
    • Análisis de gastos e ingresos estimados (Estimación por tres valores) en años. Si vendemos nuestra app a otras ONGs, cuantos usuarios u ONGs deberían ser clientes para que tuviesemos beneficios.
    • CA y estado de cumplimiento.
  • Prototipo al final del Spint 15%
  • Retrospectiva del Sprint 1 40%
    • Rendimiento del equipo
    • Des-Anonimizar al que más ha hecho y el que más ha evolucionado respecto a la semana anterior.
    • Automatización de análisis de la calidad del código
    • Problemas> Solución > Objetivo > Análisis de la solución
    • Reloj del avance del proyecto (Semanal y global) Tiene que haber un enlace al clockify pero no en la Landing page.
  • Gestión de usuarios pilotos
    • Mostrar gráficamente la ventana de disponibilidad, ventana de feedback de usuarios, etc.

Semana 5

Aspectos importantes para la presentación

• El elevator pitch debe ser conciso, idealmente alrededor de un minuto de duración.
• Se recomienda seguir un orden coherente en la presentación.
• Es esencial trabajar la entonación y el lenguaje para transmitir seguridad y profesionalismo.
• Se debe evitar asignar el mismo número de usuarios para todos los planes de precios, ya que cada plan podría tener un número diferente.
• Considerar la inclusión de una gráfica con estimaciones de gastos e ingresos para diferentes escenarios (pesimista, realista y optimista).
• Sería beneficioso mencionar el estado de los riesgos, así como los planes de contingencia para abordarlos.
• Se sugiere dejar espacio para demostrar las métricas de rendimiento y estadísticas relevantes.

TCO/Costes

• Es importante diferenciar entre OpEx (Gastos Operativos) y CapEx (Gastos de Capital) correctamente, especialmente en lo que respecta a los sueldos de los desarrolladores.
• Se debe tener en cuenta una estimación realista de los costos, considerando tanto los gastos fijos como los variables.
• Incluir los costos asociados con el mantenimiento, operación y personal, así como los relacionados con herramientas y servicios utilizados en el desarrollo del proyecto.

Riesgos

• Planificar planes de contingencia para abordar los riesgos identificados durante el proyecto.
• Proporcionar una visión clara del estado actual de los riesgos y cómo se están gestionando.

Business Statement

• Elaborar un discurso empresarial claro y conciso que presente el proyecto de manera profesional y segura.
• Asegurarse de que los elementos visuales utilizados estén alineados con el mensaje y la identidad del proyecto.

Core use cases

• Mejorar la visualización de los casos de uso principales del proyecto, posiblemente mediante el uso de mockups o ejemplos concretos.

SWOT

• Revisar y mejorar el análisis SWOT, asegurándose de que los iconos utilizados sean representativos y claros.

Análisis de herramientas

• Detallar las alternativas consideradas y explicar por qué se eligió una sobre las demás.
• Proporcionar información sobre las herramientas seleccionadas y sus características clave.

Commitment agreement

• Mantener el documento del compromiso actualizado y revisar su cumplimiento regularmente.
• Incluir métricas para evaluar el cumplimiento del compromiso y proporcionar un historial de versiones para un seguimiento claro del progreso.

Semana 6

• Tener en cuenta los que se han propuesto voluntarios para participar en frontend
• Si todas las celdas de una tabla están con el mismo valor, mejor colores
• Más adelante nos pedirán un changelog de las tareas
• En el agreement incorporar una versión 4.0 en la que mencionamos que nos comprometemos a ajustarnos a las team practices. (No tener un solo revisor)
• Se puede reducir el alcance para mejorar la calidad
• Mejorar el bluejay (Hablar con Lolo)

Semana 7

Aspectos importantes para la presentación

• Es crucial seguir la estructura proporcionada por los profesores para garantizar coherencia y claridad en la presentación.
• Se debe prestar atención al tiempo asignado a cada sección para asegurar que se cumpla con el límite establecido.
• Las gráficas por sprint son esenciales para mostrar el progreso del proyecto de manera visual y comprensible.
• Es fundamental incluir las lecciones aprendidas de cara a la presentación final para demostrar el crecimiento y la mejora del equipo a lo largo del proyecto.

TCO/Costes

• Se debe distinguir entre OpEx (Gastos Operativos) y CapEx (Gastos de Capital) correctamente para una gestión financiera precisa.
• Es importante estimar los costos a largo plazo y considerar posibles fluctuaciones económicas, como la inflación.
• Incluir una medición para el análisis posterior de la solución del problema garantiza una evaluación completa de la efectividad de las acciones tomadas.

Riesgos

• Realizar un análisis detallado de la calidad de las soluciones a los problemas identificados para asegurar la efectividad de las medidas tomadas.
• El feedback de los usuarios piloto es crucial para mejorar continuamente el proyecto y garantizar su adecuación a las necesidades del usuario final.
• Es recomendable incluir un calendario que muestre cuándo se envió, recibió, analizó y utilizó el feedback de los usuarios piloto, así como un calendario para el siguiente sprint.

Business Statement

• La presentación del business model debe incluir un elevator pitch claro y conciso, un análisis de los competidores que destaque las ventajas competitivas de la aplicación y una descripción detallada del acuerdo con el cliente.
• Mejorar el storyboard en base al feedback recibido garantiza una presentación atractiva y efectiva del proceso de llegada a la solución.
• La inclusión de aspectos legales del proyecto, como el Customer Agreement y cláusulas abusivas, es esencial para garantizar la transparencia y el cumplimiento normativo.

Core use cases

• Mejorar la visualización de los casos de uso principales del proyecto para una comprensión clara y rápida de su funcionalidad.
• Es fundamental demostrar cómo la solución propuesta aborda de manera efectiva los problemas identificados y mejora la experiencia del usuario.

SWOT

• Revisar y mejorar el análisis SWOT para identificar claramente las fortalezas, debilidades, oportunidades y amenazas del proyecto.
• Garantizar que los iconos utilizados en el análisis SWOT sean representativos y claros para una comprensión rápida y efectiva.

Analisis de herramientas

• Detallar las herramientas utilizadas en el proyecto y explicar por qué se eligió una sobre las demás.
• Proporcionar información sobre las características clave de las herramientas seleccionadas y cómo contribuyen al éxito del proyecto.

Commitment agreement

• Mantener el documento de compromiso actualizado y revisar regularmente su cumplimiento para garantizar el éxito del proyecto.
• Incluir métricas para evaluar el cumplimiento del compromiso y proporcionar un historial de versiones para un seguimiento claro del progreso del proyecto.

Es importante mantener la estructura proporcionada y asegurarse de cubrir todos los aspectos relevantes durante la presentación.

Semana 8

Aspectos importantes para la presentación:

• Descripción clara antes de la demostración Es esencial proporcionar una explicación precisa de lo que se mostrará durante la demo.

• Usabilidad de la demo Se recomienda evitar un exceso de marketing al inicio y utilizar el zoom de manera moderada para no marear al espectador.

• Feedback recibido y gestión del mismo**: Se debe incluir una sección que detalle el feedback recibido y cómo se está gestionando, así como una lista priorizada por relevancia.

• Inclusión de usuarios piloto y planificación Falta mostrar la parte de usuarios piloto en la presentación, así como la planificación del proyecto.

• Storytelling en el storyboard Se sugiere que el storyboard cuente una historia coherente para mejorar la comprensión del producto.

• Icono representativo del usuario en la demo Agregar un icono sobre el vídeo de la demo que simbolice al usuario que está utilizando el sistema puede mejorar la identificación.

TCO/Costes:

• Diferenciación entre costes de mantenimiento y despliegue Es importante no confundir los costes de mantenimiento con los costes de despliegue durante la presentación.

Riesgos:

• No cumplimiento de Commitment Agreements Se recomienda incluir cláusulas que indiquen las consecuencias en caso de no cumplir con los compromisos acordados.

Business Statement:

• Impacto positivo/negativo de la IA: Se debe incluir en la presentación si la IA ha afectado positiva o negativamente al uso del producto.

Análisis de herramientas:

• Uso de colores distinguibles en gráficas: Es importante utilizar colores que sean fáciles de distinguir en las gráficas, especialmente para que sean visibles desde el fondo de la clase.

Compromiso de acuerdo:

• Inclusión de cláusulas en Commitment Agreement: Se sugiere incluir cláusulas que especifiquen las acciones a tomar en caso de incumplimiento de los compromisos acordados.

Semana 9

Presentación:

• Varios equipos recibieron críticas sobre la presentación, incluyendo problemas con el orden de las diapositivas, falta de fluidez en la entrega y problemas con la visibilidad del contenido en la pantalla. F

• Se sugiere reducir la carga de información en las diapositivas y practicar la vocalización y entonación para una mejor comprensión por parte del público. F

TCO y ROI:

• Se señala la ausencia de consideraciones sobre el GDPR en algunos proyectos. F

• Recomendaciones para mejorar la visualización y comprensión de las gráficas de costos y beneficios, así como la inclusión de aspectos como la seguridad social en el cálculo del TCO.

Demostración:

• Problemas con la claridad y la conexión entre las características presentadas. F

• Se sugiere contar una historia con la demostración para una mejor comprensión por parte del público. F

• La falta de botones de aceptación de términos y condiciones fue señalada en algunas presentaciones. F

Anuncio:

• Algunos equipos no presentaron anuncios según lo requerido, y en su lugar utilizaron elementos del storyboard.

Seguimiento:

• Se recomienda mejorar la explicación sobre cómo se están resolviendo los problemas y adoptar un enfoque sistemático para la resolución de problemas emergentes.

Pilotos / Acuerdo con el Cliente:

• Se destacó la importancia de recopilar y valorar adecuadamente el feedback de los usuarios piloto.

• Se sugiere priorizar los cambios solicitados por los usuarios piloto para mejorar la experiencia del cliente. F

Planificación / Replanificación:

• Recomendaciones para simplificar la presentación de la planificación utilizando iconos u otros recursos en lugar de diagramas de Gantt.

• La falta de un plan de pruebas también fue señalada en algunas presentaciones.

IA:

• No se proporcionaron comentarios específicos sobre el componente de IA en los proyectos evaluados.

Testing:

• Se observaron deficiencias en la estrategia de pruebas, incluyendo la falta de pruebas de rendimiento y la necesidad de un enfoque más exhaustivo para evaluar la calidad del software.

Semana 10

Feedback General

• Se observa una necesidad de mejorar la fluidez y organización de las presentaciones.
• La carga de información en las diapositivas es excesiva y dificulta la comprensión. F
• Falta uniformidad en el estilo y colores de las presentaciones. F
• Es crucial mejorar la vocalización y entonación para una mejor comunicación. F
• Se requiere una mejor adaptación del contenido al tiempo disponible.
• Es esencial trabajar en la claridad y visibilidad de las demostraciones. F
• Se sugiere una narrativa coherente y la inclusión de datos realistas en las demostraciones. F
• La falta de seguimiento sistemático y resolución de problemas es una debilidad.
• Es importante establecer indicadores de éxito y seguir un plan de resolución de problemas. F
• La planificación debe ser más clara y priorizar los cambios según la retroalimentación de los usuarios.F
• Se requiere una mejor gestión del tiempo y la inclusión de un plan de pruebas exhaustivo. F
• Se deben corregir problemas de presentación, como aspect ratios y problemas de visualización. F

Presentación

• Mejorar la estructura y organización de las diapositivas. F
• Reducir la carga de información en las diapositivas para una mejor comprensión.
• Trabajar en la uniformidad de estilo y colores. F
• Practicar la vocalización y entonación para una comunicación más efectiva. F
• Aprovechar el tiempo disponible de manera más eficiente.

TCO y ROI

• Incluir consideraciones importantes como GDPR y seguridad social en los cálculos. F
• Clarificar y mejorar la representación visual de los costos y beneficios. F

Demo

• Mejorar la narrativa y conexión entre las características demostradas. F
• Asegurar una presentación clara y visible, con datos realistas y una narrativa coherente. F
• Considerar la inclusión de un botón de aceptar términos y condiciones. F

Anuncio

• Desarrollar anuncios basados en storyboards con una narrativa clara y visualmente efectiva. F

Seguimiento

• Establecer un seguimiento sistemático de problemas y su resolución. F
• Definir indicadores de éxito y metas claras para evaluar la efectividad de las soluciones.

Pilotos / Customer Agreement

• Priorizar los cambios según la retroalimentación de los usuarios piloto.F
• Mejorar la comunicación y recopilación de feedback de los usuarios piloto.

Planificación / Replanificación

• Simplificar la planificación y evitar el uso excesivo de diagramas complejos. F
• Priorizar las funcionalidades según el tiempo disponible y la retroalimentación de los usuarios. F

IA

• Aprovechar las herramientas de IA para mejorar la generación de anuncios y presentaciones.
• Incorporar IA de manera efectiva en todas las etapas del proyecto, desde la planificación hasta el seguimiento y la resolución de problemas.

Testing

• Ampliar el alcance de las pruebas para incluir pruebas de rendimiento y responsividad. F
• Utilizar herramientas y métricas adecuadas para evaluar la efectividad de las pruebas y los errores encontrados.

Semana 11

Feedback General sobre Presentaciones

• Se ha observado una falta de sincronización entre el discurso y la presentación en PowerPoint en varios grupos.
• En varias presentaciones se ha hecho hincapié en aspectos políticos o emocionales en lugar de centrarse en aspectos técnicos.
• Se ha recomendado seguir una narrativa coherente o un hilo argumental durante las demostraciones. F
• Hay una sugerencia para mejorar la visualización y presentación de datos en las diapositivas, como el uso adecuado de gráficos y la simplificación del contenido. F
• Se ha mencionado la importancia de practicar la vocalización y entonación para una mejor comunicación durante las presentaciones. F

Feedback sobre Estudio de Costes y ROI

• En el estudio de costes, se ha sugerido incluir los costos sociales que la empresa tendría que pagar. F
• Se recomienda distinguir claramente entre salario bruto y costos sociales en los cálculos financieros. F
• Se ha planteado la necesidad de tener en cuenta el número esperado de clientes para calcular adecuadamente el ROI. F

Feedback sobre Demostraciones

• Se sugiere mejorar la narrativa y conexión entre las características demostradas durante las presentaciones. F
• En algunas demostraciones, se ha mencionado la falta de una introducción clara sobre lo que se va a ver. F
• Se ha destacado la importancia de una presentación clara y visualmente efectiva, con datos realistas y una narrativa coherente. F

Feedback sobre Seguimiento y Resolución de Problemas

• Se ha mencionado la importancia de establecer un seguimiento sistemático de problemas y su resolución, así como definir indicadores de éxito para evaluar la efectividad de las soluciones. F
• Se sugiere incluir lecciones aprendidas y problemas encontrados durante el seguimiento para mejorar el proceso de resolución de problemas. F

Feedback sobre Planificación y Replanificación

• En la planificación, se ha recomendado evitar el uso excesivo de diagramas complejos y priorizar las funcionalidades según la retroalimentación de los usuarios. F
• Se ha sugerido ser más específico en el plan de marketing, estableciendo fechas para publicaciones en redes sociales u otros eventos promocionales.

Feedback sobre IA y Testing

• Se ha mencionado la importancia de aprovechar las herramientas de IA para mejorar la generación de anuncios y presentaciones, así como su incorporación en todas las etapas del proyecto.
• En cuanto al testing, se recomienda ampliar el alcance de las pruebas para incluir pruebas de rendimiento y responsividad, así como utilizar herramientas adecuadas para evaluar la efectividad de las pruebas realizadas. F

Semana 12

Inicio y Killer Opener

• El inicio ha sido efectivo.
• El killer opener es problemático y puede suponer un fallo de entrega.
• Mejorar el killer opener para remarcar la necesidad de la aplicación.
• Un inicio más visual es recomendable, incluyendo dramatizaciones para resaltar problemas y soluciones.

Historia y Coherencia

• Generar una historia para dar coherencia y conectar las acciones de la demo.
• Seguir un hilo argumental en el video de marketing, planteando una necesidad y luego una solución.
• La historia y la funcionalidad de la aplicación deben estar correctamente aplicadas y mostradas.
• Mejorar la conexión de las partes de la presentación para evitar que las funcionalidades se enumeren fuera de contexto.

Roles y Funcionalidades

• Mostrar acciones por rol de manera lógica, sin necesidad de enumerar cada acción.
• Identificar y mostrar claramente las funcionalidades relacionadas con accesibilidad.

Costes y Ganancias

• Asegurarse de que el video de marketing esté orientado a la audiencia correcta.
• Mostrar datos o informes de gastos en anuncios de inversores.
• Juntar detalles de estimaciones de beneficios en 1-2 transparencias y explicar las fórmulas de costes y beneficios.
• Añadir cálculos sobre la recuperación de inversión y ganancias esperadas en los anuncios.
• Especificar si los costos presentados son anuales.

Competidores y Segmentación

• Usar más recursos gráficos para aclarar la información en el análisis de competidores.
• Enfocar la discusión en los competidores principales.
• Explicar mejor la segmentación del mercado, enfocándose en el mercado objetivo más beneficioso y las redes sociales óptimas.

Presentación y Conexión de Partes

• Unificar el estilo de los símbolos de dinero (K€).
• Responder a dudas que puedan tener usuarios e inversores en el video de presentación.
• Hilar mejor las partes de la presentación y evitar añadir información de roles adicionales innecesariamente.
• Eliminar diapositivas innecesarias y mover información relevante al anuncio de inversores.

Marketing y Anuncios

• Evitar contenido que no corresponda a mostrar la funcionalidad del proyecto en las campañas de marketing.
• Indicar las necesidades de las personas en la parte de la campaña de lanzamiento.
• Proveer ejemplos de cómo podría ser la campaña de marketing, como banners en periódicos y anuncios en televisión.
• Continuar con la historia del anuncio en la demo de la aplicación.

Calidad Audiovisual y Energía

• La presentación debe ser clara, atractiva, y presentada con energía.
• Presentar con energía y asegurarse de que se entienda bien cómo obtener más información.